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What  is  SOA? 


Service-oriented  architecture  is  a  way  of  designing,  developing,  deploying 
and  managing  systems,  in  which 

•  Services  provide  reusable  business  functionality  with  well-defined  interfaces. 

•  Service  consumers  are  built  using  functionality  from  available  services. 

•  Service  interface  definitions  are  first-class  artifacts. 

There  is  clear  separation  of  service  interface  from  service  implementation. 

•  An  SOA  infrastructure  enables  discovery,  composition,  and  invocation  of 
services. 

•  Protocols  are  predominantly,  but  not  exclusively,  message-based  document 
exchanges. 


—  SOA  Basics 
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Components  of  a  Service-Oriented  System 
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Service  Interfaces 


x 


Enterprise 
Information  System 


Internal  Users 


Legacy  or  New 
Service  Code 


Service 

Implementation 
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SOA  Entry  Points 


Usually  more 
than  one  entry 
point 


Portals,  Mashups,  Dashboards 


BPM 

Events 


Data 

Consolidation, 
Data  Services, 
Ontologies, 
Semantic 
Mediation, ... 


We  will  focus 
on  this  entry 
point. 


Legacy  Services,  Integration  Services,  Adapter  Services, 

Source:  Adapted  from  AgilePath’s  SOA  Quad  Model™ 
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Legacy  System  Reuse  in  the  SO  A  Context 


Reuse  at  a  higher  level 

•  Reuse  of  business  functionality 

•  Encapsulation  of  technical  details 


Reuse  across  organizations 


f  I 


•  Organizations  can  “sell”  their  core  business  expertise  as  services. 

•  Functionality  can  be  acquired  as  opposed  to  developed  from  scratch — 
potential  savings. 

Option  for  leveraging  legacy  system  investment 

•  In  many  cases,  legacy  components  can  be  reused  by  exposing  them  as 
services,  independent  of  vendor,  platform,  and  technology. 


Legacy  System  Reuse  Challenges 


Reuse  at  the  service  level  is  more  complex  than  reuse  at  the  module  or 
component  level. 

•  From  the  service  provider  perspective 

Designing  reusable  services  requires  a  different  approach,  skill  set,  and 
mindset 


Bigger  stakeholder  community  because  services  are  typically  reused  at 
organization  and  sub-organization  level 


Services  need  to  be  as  generic  as  possible  so  that  they  are  of  interest  to 
multiple  service  consumers  and  at  the  same  time  need  to  add  value  to 
potential  consumers 


•  From  the  service  consumer  perspective 

Larger  granularity  may  lead  to  larger  incompatibilities 

Challenges  can  come  from  the  legacy  system  from  itself  or  from  the 
environment. 


_  SMART 
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Bottom  Line 


There  are  issues  to  take  into  consideration  that  go  beyond  adding  a 
service  interface  to  an  existing  system. 


SMART  is  an  approach  to  make  initial  decisions  about  the  feasibility  of 
reusing  legacy  systems  within  an  SOA  environment. 


_  SMART 
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SMART:  Service  Migration  and  Reuse  Technique 


The  end  goal  for  SMART  is  the  identification  a  pilot  project  that  will  help 
shape  a  migration  strategy  for  an  organization,  along  with  an 
understanding  of  cost  and  risk  involved. 

SMART  analyzes  the  viability  of  reusing  legacy  systems  in  an  SOA 
environment: 

•  Does  it  make  sense  to  migrate  the  legacy  system  to  services? 

•  What  services  make  sense  to  develop? 

•  What  legacy  system  components  can  be  used  to  implement  these  services? 

•  What  changes  to  components  are  needed  to  accomplish  the  migration? 

•  What  migration  strategies  are  most  appropriate? 

•  What  are  the  preliminary  estimates  of  cost  and  risk? 

•  What  is  an  ideal  pilot  project  that  can  help  address  some  of  these  risks? 


—  SMART:  Introduction 
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Three  Elements  of  SMART 


Process  ^ 

SMART  Interview  / 
Guide  (SMIG) 

Artifacts  ^ 

Gathers  information  about 

Guides  discussions  in  initial 

•  Stakeholder  List 

•  Goals  and  expectations  of 
migration  effort 

•  Candidate  services 

•  Legacy  systems 

•  Target  SOA  environment 

SMART  activities 

•  Characteristics  List 

•  Migration  Issues  List 

•  Business  Process-Service 
Mapping 

•  Service  Table 

Analyzes  gap  between 
legacy  and  target  state 

•  Component  Table 

•  Notional  Service-Oriented 
System  Architecture 

•  Service-Component 
Alternatives 

•  Migration  Strategy 

—  SMART:  Elements 
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SMART  Process  Activities 


Establish 

Migration 

Context 


Migration 

Feasible? 


>—  No*- 


T 

Yes 


Define 

Candidate 

Services 

Describe 

Existing 

Capability 


► 


Analyze  the 
Gap 


<4 


Develop 

Migration 

Strategy 
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Establish  Migration  Context 


Establish 

Migration 

Context 


T 


Migration 

Feasible? 


— No> 


I 

Yes 


Understand  the  business  and  technical 
context  for  migration 

•  Rationale,  goals  and  expectations 

•  Technical  and  business  drivers 

•  Programmatic  constraints  (e.g.  schedule, 
budget) 

•  Previous  related  efforts  or  analyses 

Identify  stakeholders 

•  Who  is  driving  and  paying  for  the  effort 

•  Who  knows  what  about  the  legacy  system  and 
the  target  SOA  environment 

•  Demand  or  need  for  potential  services 

Understand  legacy  system  and  target  SOA 
environment  at  a  high  level 

Identify  a  set  of  candidate  services  for 
migration 


—  SMART:  Establish  Migration  Context 
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Establish  Migration  Context:  SMIG  Examples 


Discussion 

Topic 

Related  Questions 

Potential  Migration  Issues 

Goal  and 
Expectations 
of  Migration 
Effort 

•  What  are  the  business  and  technical  drivers 
for  the  migration  effort? 

•  What  are  the  short-term  and  long-term 
goals? 

•  No  SOA  strategy 

•  Goals  for  migration  are  not  clear. 

High-Level 
Understanding 
of  Legacy 
System 

•  What  is  the  main  functionality  provided  by 
the  legacy  system? 

•  What  is  the  high-level  architecture  of  the 
system? 

•  What  is  the  current  user  interface  to  the 
system? 

•  Legacy  system  knowledge  is  not 
available. 

•  Architectural  mismatch 

•  User  interface  complexity  hard  to 
replicate  in  service  consumers 

High-Level 
Understanding 
of  Target  SOA 
Environment 

•  What  are  the  main  components  in  the  target 
SOA  environment? 

•  Is  this  the  organization’s  first  attempt  to 
deploy  services  in  this  environment? 

•  Target  SOA  environment  has  not 
been  identified. 

•  No  in-house  knowledge  of  target 
SOA  environment 

Potential 

Service 

Consumers 

•  Who  are  the  potential  service  consumers? 

•  Consumers  for  services  have  not 
been  identified. 

—  SMART:  Establish  Migration  Context 
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Case  Study:  Establish  Migration  Context 


DoD  organization  tasked  with  developing  services  that  can  be  used  by 
mission  planning  and  execution  applications 

MSS  is  a  system  for  comparison  of  planned  mission  against  current  state 
to  determine  if  corrective  actions  should  be  taken 

•  In  final  stages  of  development 
Drivers 

•  Migration  to  services  was  already  a  longer-term  goal  for  MSS 

•  Make  developed  services  available  to  all  mission  planning  and  execution 
systems 

Requirement  to  demonstrate  the  feasibility  of  one  component  as  a  service 
being  used  by  one  mission  planning  and  execution  system  within  6  months 
and  to  migrate  the  full  system  to  services  in  two  years 


—  SMART  Case  Study:  Establish  Migration  Context 
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Case  Study:  Establish  Migration  Context  2 


Standard  Web  Services  environment  is  target  SOA  environment 

•  Not  clear  that  this  will  be  the  future  environment  for  the  developed  services 

Representatives  from  the  legacy  system  and  a  representative  from  a  mission 
planning  and  execution  application  (service  consumer)  agreed  on  the 
following  candidate  services 

•  AvailablePlans :  Provides  list  of  available  plans  that  are  being  reasoned  about. 

•  TrackedTasksPerPlarr.  Provides  list  of  tasks  that  are  being  tracked  for  a 
certain  plan. 

•  TaskStatus :  Provides  the  status  for  a  given  task  in  a  given  plan. 

•  SetTaskAlert  Alerts  when  a  given  task  in  a  given  plan  satisfies  a  certain 
condition 


—  SMART  Case  Study:  Establish  Migration  Context 

=^p-  Software  Engineering  Institute  Carnegie  Mellon  version  1.7^1  w^ina^i  2009  17 

©2009  Carnegie  Mellon  University 


Checkpoint  for  Migration  Feasibility 


Establish 

Migration 

Context 


Migration 

Feasible? 


-N 


Yes 


Decision  to  continue  with  the 
process  has  to  be  made 

Potential  outcomes  at  this  point  are 

•  The  migration  is  initially  feasible 

•  The  migration  has  potential  but 
requires  additional  information  to 
make  an  informed  decision 

•  The  migration  is  not  feasible 


Develop 

Migration 

Strategy 


—  SMART:  Migration  Feasibility  Checkpoint 
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Case  Study:  Migration  Feasibility 


Decision:  Migration  feasible 

•  Availability  of  stakeholders  from  the  service  provider  and  a  service  consumer 

•  Good  understanding  of  the  legacy  system 

•  Request-response  nature  of  the  identified  services 

•  Reasonable  initial  mapping  of  services  to  components 

Migration  issues  identified  in  this  activity 

•  Short-term  goal  for  the  migration  is  different  from  long-term  goal  migration 

8  Work  to  accomplish  the  short-term  goal  might  have  to  be  redone  in  order  to 
accomplish  the  long-term  goal 

•  System  is  a  single-user,  single-plan  system 

When  capabilities  are  migrated  to  services,  it  will  have  to  support  multiple  users 
and  multiple  plans 


—  SMART:  Migration  Feasibility  Checkpoint 
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Candidate  Services 


Establish 

Migration 

Context 


Migration  _N  ^ 
Feasible? 


Yes 


Select  a  small  number  of  services, 
usually  3-4,  from  the  initial  list  of 
candidate  services 

For  these  candidate  services,  the  end 
goal  is  to  fully  specify  inputs  and 
outputs 


SMART:  Define  Candidate  Services 
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Case  Study:  Define  Candidate  Services 


The  list  of  services  identified  in  the  previous  step  was  considered  reasonable  for 
analysis 

Inputs  and  outputs  were  next  identified  in  detail  for  each  of  these  services 
Migration  issues  identified  in  this  activity 

•  SetTaskAlert  requires  (1 )  alert  is  set  up  to  respond  to  certain  conditions  and  (2)  service 
consumer  is  alerted  when  the  condition  is  reached 

—  Handling  of  events  in  service-oriented  environments  is  relatively  new — SOA  2.0 

•  Unclear  how  the  alert  mechanism  is  going  to  be  implemented 

—  SOA  infrastructure  would  need  to  have  a  way  to  call  back  the  service  consumer 
—  There  might  also  be  firewall  issues  on  the  consumer  side 

•  Complexity  of  alert  conditions  is  high 

—  Service  consumer  interface  will  have  to  replicate  this  complexity  or  conditions 
would  have  to  be  made  simpler  or  limited 


—  SMART  Case  Study:  Define  Candidate  Services 
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Describe  Existing  Capability 


Establish 

Migration 

Context 


Migration 

Feasible? 


>-No^ 


I 

Yes 


Obtain  descriptive  data  about  legacy 
components 

•  Name,  function,  size,  language,  operating 
platform,  age  of  legacy  components,  etc. 

Question  technical  personnel  about 

•  Architecture  and  design  paradigms 

•  Complexity,  coupling,  interfaces 

•  Quality  of  documentation 

•  Component/product  dependencies 

Gather  data  about 

•  Quality,  maturity,  existing  problems 

•  Change  history 

•  User  satisfaction 


—  SMART:  Describe  Existing  Capability 
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Describe  Existing  Capability:  SMIG  Examples 


Discussion 

Topic 

Related  Questions 

Potential  Migration  Issues 

Legacy  System 
Characteristics 

•  What  is  the  history  of  the  system? 

•  Is  the  system  a  proof  of  concept,  prototype,  under 
development,  in  testing,  or  a  fielded  system? 

•  What  system  documentation  is  available? 

•  Does  the  system  have  interfaces  to  other 
systems? 

•  What  are  potential  locking,  persistence,  or 
transaction  problems  if  accessed  by  multiple  users 
when  migrated  to  services? 

•  Planned  development  concurrent  with 
service  migration 

•  Limited  system  documentation 

•  Interfaces  to  other  systems  will  open 
doors  to  service  consumers. 

•  Single-user  system  may  have  problems 
in  a  multi-user  environment. 

Legacy  System 
Architecture 

•  What  architecture  views  are  available? 

•  What  are  the  major  modules  of  the  system  and 
dependencies  between  modules? 

•  Is  user  interface  code  separate  from  the  business 
logic  code? 

•  Are  there  any  design  paradigms  or  patterns 
implemented  in  the  system? 

•  What  are  the  key  quality  attributes  built  into  the 
current  architecture  of  the  system? 

•  Lack  of  architecture  documentation 
may  lead  to  underestimation  of 
complexity. 

•  Tight  coupling  between  user  interface 
code  and  business  logic  code 
increases  effort. 

•  Undocumented  violations  of  design 
patterns  may  cause  problems. 

•  Key  quality  attributes  may  not  hold  true 
in  a  services  environment. 

Code 

Characteristics 

•  What  code  documentation  is  available? 

•  What  coding  standards  are  followed? 

•  Poor  coding  practices  will  increase 
migration  effort. 

—  SMART:  Describe  Existing  Capability 
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Case  Study:  Describe  Existing  Capability 


MSS  characteristics 

•  In  demonstration  state 

•  Written  in  C++,  C#  and  Managed  C++  in  a  Visual  Studio  2005  development  environment 

•  Runs  on  a  Windows  XP  platform 

•  Size  of  the  full  system  is  approximately  1 3,000  lines  of  code 

•  Code  documentation  was  rated  between  Fair  and  Good  by  its  developers 

Several  architecture  views  were  presented  that  were  useful  for  understanding  the  system 
MSS  relies  on  an  external  planning  system  (PS)  for  plan  data  and  situational  awareness  data 

•  PS  is  being  targeted  for  migration  to  services  in  the  future 

Migration  issues  identified  in  this  activity 

•  Documentation  for  most  of  the  analyzed  classes  was  determined  Fair 

—  Could  be  an  issue  if  original  developers  do  not  perform  the  migration 

•  Currently  a  large  amount  of  communication  between  MSS  and  PS 

—  Unclear  how  performance  will  be  affected  when  this  communication  takes  place  using  services 
(they  currently  reside  on  the  same  machine) 

•  Task  alert  functionality  is  not  currently  implemented  in  MSS 

—  Still  unknowns  about  the  specifics  of  the  implementation 


—  SMART  Case  Study:  Describe  Existing  Capability 
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Describe  Target  SOA  Environment 


Establish 

Migration 

Context 


Migration 

Feasible? 


>-No^ 


I 

Yes 


Develop 

Migration 

Strategy 


Identify  the  impact  of  specific 
technologies,  standards,  and 
guidelines  for  service 
implementation 

Determine  state  of  target  SOA 
environment 

Identify  how  services  would 
interact  with  the  SOA 
environment 

Determine  QoS  expectations 
and  execution  environment  for 
services 


—  SMART:  Describe  Target  SOA  Environment 
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Describe  Target  SOA  Environment:  SMIG 
Examples 


Discussion 

Topic 

Related  Questions 

Potential  Migration  Issues 

IsOA 

•  What  is  the  status  of  the  target  SOA  environment? 

•  Target  SOA  environment  undefined 

Environment 

•  What  are  the  major  components  of  the  SOA 

•  Redundancy/conflicts  between 

Characteristics 

infrastructure? 

•  Does  the  target  SOA  environment  provide 
infrastructure  services  (i.e.,  communication, 
discovery,  security,  data  storage)? 

•  What  is  the  communication  model? 

•  What  constraints  does  the  target  SOA  environment 
impose  on  services? 

•  Does  the  legacy  system  have  any  behavior  that 
would  be  incompatible  with  the  target  SOA 
environment? 

•  Once  developed,  where  will  services  execute? 

infrastructure  services  and  legacy  code 

•  Lack  of  tools  to  support  legacy  code 
migration  to  target  infrastructure 

•  Compliance  with  constraints  requires 
major  effort. 

•  Architectural  mismatch 

•  No  thought  given  to  service  deployment 
and  execution 

Support 

•  Do  you  have  to  provide  automated  test  scripts  for 
the  services  and  make  them  publicly  available? 

•  How  will  service  consumers  report  problems  and 
provide  feedback? 

•  How  will  service  consumers  be  informed  of 
potential  changes  in  service  interfaces  and 
downtime  due  to  upgrades  or  problems? 

•  Underestimation  of  effort  to  provide 
service  consumer  support 

•  Lack  of  awareness  of  support 
requirements 

—  SMART:  Describe  Target  SOA  Environment 
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Case  Study:  Notional  Service-Oriented  System 
Architecture 


Mission 
Planning  and 
Execution 
Application 

Service  Consumer 


Microsoft  IIS  and  ASP.NET 


Alert 

Component 


SOA  Infrastructure 


Mission 

Status 

Service 


AvailablePlans 
T  rackedT  asksPerPlan 
TaskStatus 
SetTaskAlert 


Data 


Service  Code 


—  SMART  Case  Study:  Describe  Target  SOA  Environment 
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Case  Study:  Describe  Target  SOA  Environment 


Migration  issues  identified  in  this  activity 

•  Not  known  if  the  identified  publish-subscribe  component  to  facilitate  alerts  will 
allow  someone  to  subscribe  on  behalf  of  a  third  party 

If  not,  the  service  consumer  will  have  to  be  aware  of  the  dependency  on 
the  publish-subscribe  component 

Ideal  situation  would  be  for  the  SetTaskAlert  service  code  to  subscribe  on 
behalf  of  the  service  consumer,  so  that  the  service  consumer  is  not 
affected  if  the  alert  mechanism  changes 

•  If  the  service  consumer  has  to  be  set  up  as  a  Web  server,  it  would  have  to  be 
configured  so  that  it  accepts  incoming  messages  from  the  publish-subscribe 
component 

Potential  security  concern 


—  SMART  Case  Study:  Describe  Target  SOA  Environment 
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Analyze  the  Gap 


Establish 

Migration 

Context 


Migration 

Feasible? 


>-No^ 


I 

Yes 


=  Software  Engineering  Institute 


G 


•  Define  effort,  risk  and  cost  to 
migrate  legacy  components, 
given  candidate  service 
requirements  and  target  SOA 
characteristics 

•  Determine  need  for  additional 
analyses 


SMART:  Analyze  the  Gap 
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Case  Study:  Analyze  the  Gap 


Developers  were  asked  to 

•  Describe  the  details  of  the  changes  that  would  have  to  be  made  to  the  code 
given  the  service  requirements,  the  service  inputs  and  outputs,  as  well  as  the 
characteristics  and  components  of  the  target  SOA  environment 

•  Provide  an  estimate  of  the  effort  required  to  make  these  changes 

No  code  analysis  or  architecture  reconstruction  was  necessary  because 

•  Original  developers  were  involved  in  the  process 

•  Input  was  credible 

•  Architecture  documentation  and  knowledge  of  the  system  were  acceptable 


SMART  Case  Study:  Analyze  the  Gap 
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Exercise:  Analyze  the  Gap — Updated  Component  Table 


COMPONENT 

MIGRATION  FACTORS 

MIGRATION  ESTIMATES 

ID 

Component  Name 

Migration 

Method 

Summary  of  Changes  Required 

Level  of 
Difficulty 

Level  of 
Risk 

Effort 

(Person- 

weeks) 

Cost 

1 

ComparisonEngine 

New  + 
Extraction 

1 .  Add  methods  to  store  and  retrieve  plan  name  and  IDs 

2.  Add  class  to  process  service  requests  from  all  4  services 

3.  Make  changes  to  handle  multiple  plans 

4.  Define  structure  of  a  condition 

Medium 

Low 

5 

$ 

2 

Analyzer 

New  + 
Extraction 

1 .  Add  methods  to  get  tasks  by  plan 

2.  Modify  all  methods  that  retrieve  tasks  to  retrieve  tasks  per  plan 

Low 

Low 

1 

$ 

3 

Task 

New  + 
Extraction 

1 .  Add  methods  to  get  and  set  plan  that  a  task  is  connected  to 

2.  Modify  constructor  to  set  new  attribute 

3.  Modify  toXML  and  fromXML  to  serialize  and  deserialize  new 
attribute 

Low 

Low 

1 

$ 

5 

AlertCondition 

New  + 
Extraction 

Option  1 : 

1 .  Add  method  to  allow  dynamically  created  parameters 

2.  Modify  constructor  to  initialize  parameters 

3.  Modify  toXML  to  serialize  parameters 

4.  Add  fromXML  method  to  deserialize  a  condition 

Medium 

Low 

2 

$ 

6 

Query 

New  + 
Extraction 

Option  2: 

-  Add  class  for  nodes  to  represent  a  task 

-  Add  class  for  nodes  to  represent  a  task  status 

-  Modify  xml2Query  class  to  serialize  task  and  task  status 

Medium 

Medium 

2 

$ 

7 

Alert 

New  + 
Extraction 

Option  2: 

-  Add  triggers  to  send  an  alert  to  alert  component 

-  Make  changes  to  constructor  to  deserialize  task  and  task  status 

Medium 

Medium 

2 

$ 

8 

AlertEngine 

New  + 
Extraction 

Option  2: 

-  Send  alert  to  alert  component 

Medium 

Medium 

2 

$ 

TOTALS 

Option  1  for  SetTaskAlert 

20 

Option  2  for  SetTaskAlert 

24 

Without  SetTaskAlert 

11 

Without  SetTaskAlert  and  without  separation  from  PS 

7 

—  SMART  Case  Study:  Analyze  the  Gap 
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Develop  Migration  Strategy 


Establish 

Migration 

Context 


Migration 

Feasible? 


>— NoH 


I 

Yes 


Define 

Candidate 

Services 


Describe 

Existing 

Capability 


Describe 
Target  SO  A 
Environment 


Analyze  the 
Gap 


Develop 

Migration 

Strategy 


Develop  a  migration  strategy  that 
that  makes  sense  for  the 
organization  and  addresses  the 
identified  migration  issues,  e.g. 

•  Feasibility,  risk  and  options  for 
proceeding  with  the  migration  effort 

•  Identification  of  a  pilot  project 

•  Order  in  which  to  create  additional 
services 

•  Guidelines  for  identification  and 
creation  of  services 

•  Options  for  source  of  service 
implementation  code 

•  Mechanisms  for  providing  service 
functionality 

•  Specific  migration  paths  to  follow 

•  Needs  for  additional  information, 
training,  technology  evaluation,  ... 


SMART:  Develop  Migration  Strategy 
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Case  Study:  Migration  Strategy 


1 .  Define  scope  of  initial  migration  for  short-term  feasibility  demonstration 

•  Decision  of  what  services  to  implement  and  whether  they  would  have  time 
to  separate  MSS  from  PS 

2.  Define  scope  of  subsequent  iterations 

•  Will  depend  on  additional  services  to  be  created  from  MSS  as  well  as 
progress  made  in  the  migration  of  PS  to  services 

3.  Finalize  service  inputs  and  outputs 

•  Alert  condition  structure  was  still  undefined 

4.  Gather  information  about  the  publish-subscribe  component  to  be  used 
as  the  mechanism  for  alert  capability 

•  Alert  mechanism  was  a  big  unknown 


—  SMART  Case  Study:  Develop  Migration  Strategy 
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Case  Study:  Migration  Strategy  2 


5.  Create  a  service  reference  architecture 


Isolates  from 
changes  in 
data  source 
(e.g.  Plan  data) 


Service  Interface  Layer 

Performs  transformations  between  messages  from 
service  consumers  and  service  code 

J 

Service  Code  Layer 

Contains  existing  service  code  plus  new  code  developed 

to  meet  service  requirements 

Data  Access  Layer 

Alert  Setup  Layer 

Contains  code  to  access  external 

Contains  code  to 

data  sources 

set  up  alerts 

Isolates  from 
changes  in 
messaging 
portion  of  SOA 


Isolates  from 
changes  in 
alert 

mechanism 


6.  Adjust  estimates 

7.  Create  MSS  services  using  the  service  reference  architecture 

8.  Document  lessons  learned 


—  SMART  Case  Study:  Develop  Migration  Strategy 
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Agenda 


SOA  Basics 

SMART  (Service  Migration  and  Reuse  Technique) 
Summary 


Conclusions 
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Summary 


SOA  offers  significant  potential  for  leveraging  investments  in  legacy 
systems  by  providing  a  modern  interface  to  existing  capabilities,  as  well  as 
exposing  legacy  functionality  to  a  greater  number  of  users 

SMART  analyzes  the  viability  of  reusing  legacy  systems  in  an  SOA 
environment: 

•  Does  it  make  sense  to  migrate  the  legacy  system  to  services? 

•  What  services  make  sense  to  develop? 

•  What  legacy  system  components  can  be  used  to  implement  these  services? 

•  What  changes  to  components  are  needed  to  accomplish  the  migration? 

•  What  migration  strategies  are  most  appropriate? 

•  What  are  the  preliminary  estimates  of  cost  and  risk? 

•  What  is  an  ideal  pilot  project  that  can  help  address  some  of  these  risks? 


—  Summary 
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Resources  and  Training 


SMART  Report 

•  http://www.sei.cmu.edu/publications/documents/08.reports/08tn008.html 

Public  Courses 


•  Migration  of  Legacy  Systems  to  SOA  Environments 
http://www.sei.cmu.edu/products/courses/p59b.html 

•  SMART  Training  Workshop 
http://www.sei.cmu.edu/products/courses/p73.html 

Certification 

•  SMART  Team  Lead 

http://www.sei.cmu.edu/certification/soasmart.html 
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SATURN  2009 
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ARCHITECTURE  AT  ALL  SCALES 

Fifth  SEI  Architecture  Technology 
User  Network  Conference 


SATURN*  S 


May  4-7,  2009  |  Radisson  Greentree  |  Pittsburgh,  Pennsylvania 


Are  you  interested  in  learning  more?  Visit  http://www.sei.cmu.edu/architecture/saturn/ 
to 


SATURN 


TECHNOLOGY 


Find  out  about  the  SEI  software  architecture  work,  current  research, 
tools  and  practices,  news,  and  how  the  SEI  can  help  you. 


SATURN 


NETWORK 


Stay  connected  to  architecture  experts  through  the  SATURN  Network  on 
Linkedln. 


SATURN 

2009 


Attend  SATURN  2009  -  the  annual  conference  that  brings  together 
experts  from  around  the  world  to  exchange  best  practices  in  developing, 
acquiring,  and  maintaining  software,  systems,  and  enterprise 
architecture.  Registration  is  now  open! 
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SOA  Topics  at  SATURN  2009 


Course:  Migrating  Legacy  Systems  to  SOA  Environments  (Grace  Lewis 
and  Dennis  Smith,  SEI,  USA) 

Tutorial:  Pattern-Oriented  Software  Architecture:  A  Pattern  Language  for 
Distributed  Computing  (Doug  Schmidt,  Vanderbilt  University,  USA) 

Papers 

•  Career  Track  for  Architects  in  IT  Service  Provider  Organizations  (Shankar 
Kambhampaty,  Satyam  Computer  Services  Limited,  India) 

•  How  Acquisition  Practice  Can  Impede  SOA  Governance  (Lloyd  Brodsky, 
CSC,  USA) 


SATURN 

2009 
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MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE  ANY  WARRANTY  OF  ANY 
KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT,  TRADEMARK,  OR  COPYRIGHT 
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